Various forms of network-based storage systems are known today. These forms include network attached storage (NAS), storage area networks (SANs), and others. Network storage systems are commonly used for a variety of purposes, such as providing multiple users with access to shared data, backing up critical data (e.g., by data mirroring), etc.
A network-based storage system typically includes at least one storage server, which is a processing system configured to store and retrieve data on behalf of one or more client processing systems (“clients”). In the context of NAS, a storage server may be a file server, which is sometimes called a “filer”. A filer operates on behalf of one or more clients to store and manage shared files. The files may be stored in a storage subsystem that includes one or more arrays of mass storage devices, such as magnetic or optical disks or tapes, by using RAID (Redundant Array of Inexpensive Disks). Hence, the mass storage devices in each array may be organized into one or more separate RAID groups.
In a SAN context, a storage server provides clients with block-level access to stored data, rather than file-level access. Some storage servers are capable of providing clients with both file-level access and block-level access, such as certain Filers made by Network Appliance, Inc. (NetApp®) of Sunnyvale, Calif.
In file servers, data is stored in logical containers called volumes, which may be identical with, or subsets of, aggregates. An “aggregate” is a logical container for a pool of storage, combining one or more physical mass storage devices (e.g., disks) or parts thereof into a single logical storage object, which contains or provides storage for one or more other logical datasets at a higher level of abstraction (e.g., volumes). A “volume” is a set of stored data associated with a collection of mass storage devices, such as disks, which obtains its storage from (i.e., is contained within, and may be coextensive with) an aggregate, and which is managed as an independent administrative unit, such as a complete file system. A “file system” is an independently managed, self-contained, hierarchal set of data units (e.g., files, blocks or LUNs). Although a volume or file system (as those terms are used herein) may store data in the form of files that is not necessarily the case. That is, a volume or file system may store data in the form of other units, such as blocks or LUNs.
One feature which is useful to have in a storage server is the ability to create a read-only, persistent, point-in-time image (RPPI) of a dataset, such as a volume or a LUN, including its metadata. This capability allows the exact state of the dataset at a particular point in time to be restored from the RPPI in the event of, for example, data corruption or accidental data deletion. The ability to restore data from an RPPI provides administrators with a simple mechanism to revert the state of their data to a known previous point in time as captured by the RPPI. Typically, creation of an RPPI or restoration from an RPPI can be controlled from a client-side software tool. An example of an implementation of an RPPI is a Snapshot™ generated by SnapDrive™ or SnapManager® for Microsoft® Exchange software, both made by NetApp. Unlike other RPPI implementations, NetApp Snapshots do not require duplication of data blocks in the active file system, because a Snapshot can include pointers to data blocks in the active file system, for any blocks that have not been modified since the Snapshot was created. The term “Snapshot” is used in this document without derogation of Network Appliance, Inc.'s trademark rights. The “active” file system is the current working file system, where data may be modified or deleted, as opposed to an RPPI, which is a read-only copy of the file system saved at a specific time.
An example of an RPPI technique, which does not require duplication of data blocks to create an RPPI, is described in U.S. Pat. No. 5,819,292, which is incorporated herein by reference, and which is assigned to Network Appliance. Among other advantages, this technique allows an RPPI to be created quickly, helps to reduce consumption of storage space due to RPPIs, and reduces the need to repeatedly update data block pointers as was required in some prior art RPPI techniques.
In order to improve reliability and facilitate disaster recovery in the event of a failure of a storage system, its associated disks or some portion of the storage infrastructure, it is common to “mirror” or replicate a dataset. Here, the term “mirror” refers to a replica of a dataset. The term “mirroring” refers to the process of creating a mirror for a data set. The original dataset is also called a “source dataset” with respect to the mirror. A dataset is a set of data. Examples of datasets include, e.g., a file system, a volume, a directory, a file, or an RPPI of any of the above.
Conventional mirroring and archival backup systems typically include processes to ensure that a dataset is correctly mirrored, to thereby prevent any inconsistencies between the mirror and the original dataset. However, errors may occur in the archival backup or mirror due to, e.g., network errors, software errors and/or physical media errors of the storage devices. As a result of such errors, the mirror/backup may not be identical to the original dataset, which may cause data loss should an error condition occur on the source system. Data inconsistency caused by errors or data corruptions is called “divergence”, as opposed to “lag” which refers to data inconsistency which occurs when a mirror or archival backup is not timely updated to reflect any latest changes of the original dataset. To ensure that a correct mirror is on the destination, a new mirroring relationship may need to be established and an initial baseline backup operation may need to be performed of the dataset. This adds management overhead. Furthermore, significant additional storage capacity is needed to create new mirroring relationship.